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Abstract 


Remote Tutor is an Internet telesemmarmg tool on MS Windows plat- 
form With this application, a tutor can lecture and interact with students 
through voice, slides, graphics and text The application uses whiteboard, 
a window shared among the group, to display PostScript slides, exchange 
graphics and multifont text in a multicast environment 

An earlier telesemmarmg tool ShdeTalk was implemented on the Win 
3 11 platform However, the voice delivery on this was defective In this 
thesis, ShdeTalk is upgraded to Remote Tutor with many new features and 
the voice component has been redesigned yielding telephone quality voice, as 
specified for the application 

An important feature of Remote Tutor is the capability for offline lecture 
organisation, recording and storage The tutor can organise a lecture in units 
and store these units m a predefined sequence, before lecture delivery using 
a GUI based organising aid developed as a part of this thesis We also allow 
recording and storage of a lecture and delivery of a stored lecture Also, the 
tutor could view the organisation of the lecture during delivery 

The application is designed completely under ObjectWindows environ 
ment and uses IP multicast for communication between members UDP is 
the underlying transport protocol 
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Chapter 1 
Introduction 


The widespread use of the Internet by millions of students makes the In 
ternet a very convenient vehicle for delivery of educational content Many 
colleges and universities offer Internet based distance learning in addition to 
traditional instruction methods Remote Tutor is a teleseminarmg tool that 
could be used for a ‘ seminar ’ in which the audience could be anywhere on 
the Internet In this thesis we introduce the Remote Tutor and describe the 
various features that have been developed for this tool as a part of this thesis 
work 


1 1 Previous Implementations for Telesemi- 
naring Tool 

In the Telematics laboratory, the first work done towards a teleseminarmg 
tool was the design and implementation of the whiteboard by Gupta and 
Mukhopadhyay [1] They used multicast for communication among group 
members It provided the basic functions for sending graphics and text to a 
multicast group The packetisation of the data is handled by the application 
The communication is free mode which, in this case means that there is no 
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limit on the number of members interacting at the same time The design of 
the whiteboard is object oriented Separate layers have been designed to in 
terface with MSWmdows sockets, packetisation and transmission of data and 
session control The highest abstraction allows the user to draw a graphical 
object or write text on the white board 

The next component of a telesemmarmg tool was by Gupta [2] when the 
capability to display slides was integrated into the whiteboard of Gupta and 
Mukhopadyay and the tool was now called ShdeTalk In this implementation, 
the public domain application GhostView was used to display postscript file 
on the whiteboard To display a slide, the same slide is first opened m the 
GhostView application and then imported onto the display window When a 
slide is displayed on the speaker’s console, information regarding the opening 
of the slide is multicast to the group Using the graphics and text functions 
developed for the whiteboard, the speaker could annotate over the slide 
Audio and video files could also be played from this application It is assumed 
that a copy of the slide file and the audio and video files resides at the users 
Kohli [3] also contributed to ShdeTalk by implementing the delivery of 
the voice component of the lecture live over the network A Sound Blaster 
compatible WAVE device was assumed to be available at all the users and 
voice was digitised using 8 bit PCM code There were some design prob- 
lems in this implementation and the quality of the reproduced voice was not 
satisfactory 

1 2 Remote Tutor 

ShdeTalk had the basic features for telesemmarmg and Remote Tutor was 
conceived to build upon these features to obtain a fullfledged, versatile and 
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user friendly teleseminaring tool To enable the metamorphosis of SlideTalk 
into Remote Tutor , considerable features and capabilities were needed and 
these are defined m the specifications [4] 

The goal of Remote Tutor is to facilitate lecture/seminar delivery over 
an internet onto the participant’s desktop A seminar /lecture is delivered 
with the speaker/tutor interacting with participants through PCs that are 
connected to a LAN or internet A graphical user interface (GUI) provides 
a user friendly environment during the seminar 

The Remote Tutor application supports interactive, real-time lecture de 
livery from a computer connected to a network that supports TCP/IP with 
multicast capability It allows the tutor to deliver lectures using text, view 
graphs, graphics, audio and video files The viewgraphs can be annotated 
over by the tutor Students can ask questions and make comments during 
the session using either the whiteboard of this application or by speaking up 
Remote Tutor also provides a facility to prepare a lecture offline, 1 e , a 
tutor can record a lecture prior to the actual session time The recorded 
lecture is stored as a lec file, and when the session is on, the tutor could 
play back this recorded lecture file instead of presenting it live Also, by 
downloading this recorded lecture file from Lecture Manager a student can 
browse through this lecture, offline, at leisure 

1 3 Scope of this Thesis 

As mentioned earlier, a voice component existed in a previous implement a 
tion but there were design problems giving rise to a clipping effect m the 
reproduced voice Our first aim was to improve the sound quality by re 
designing the voice component before integrating it into Remote Tutor 
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A tutor who uses Remote Tutor application to deliver a lecture, needs 
to organise the lecture into an appropriate number of lecture units Each of 
these lecture units will have associated with it, one postscript file and a num 
ber of audio and video files It is necessary to store this lecture organisation 
m a file to facilitate scrolling among the slide files and also sequencing the 
lecture units for lecture delivery The tutor may also have to view this lecture 
organisation while delivering the lecture Our second aim was to implement 
the above mentioned task 

In an application like Remote Tutor , the lecture once delivered online is 
needed to be stored for future use Also, the tutor may sometimes need to 
deliver a recorded lecture Our third aim was to achieve this objective The 
mam issue m the implementation of this feature was to capture the associa 
tions of various real time activities like display of a slide, the annotations on 
it, to voice for recording and maintaining them during playback Also we 
needed to make the code reasonably efficient so as to keep the computer disc 
access time combined with the worst case data processing time for record 
mg and playback, lower than the mean time between two data generation 
instants The real time nature of the voice data that has to be recorded, 
makes the above condition all the more stringent 

1 4 Organisation of the Thesis 

In Chapter 2 we discuss the Remote Tutor specifications and previous lm 
plementations in more detail The whiteboard of Gupta and Mukhopadhyay 
and ShdeTalk of Gupta and Kohli are integrated into the Remote Tutor We 
also overview these implementations Chapters 3 and 4 discuss our imple 
mentations The redesigned voice component implementation is covered in 
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chapter 3 We compare the earlier implementation with the redesigned one 
and emphasise the differences Chapter 4 discusses the issues and implemen 
tation details of lecture organisation, lecture storage and offline delivery of a 
stored lecture Chapter 5 concludes the thesis 
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Chapter 2 


Previous Teleseminaring Tools 
and Remote Tutor 
Specifications 


This chapter discusses the earlier versions of teleseminaring tools that were 
developed in the Telematics Laboratory of the EE Deptt, IIT Kanpur These 
implementations have been used to develop the Remote Tutor application 
We then describe the specifications of the Remote Tutor in detail as given in 
the specification document [4] and paper [5] 

2 1 Previous Implementations 

The system architecture of Remote Tutor is as shown in the Figure 2 1 The 
details given in this section are based on the works of Gupta and Mukhopad 
hyay [1], Gupta [2], Kohli [3] and Madhu Bajpai 

2 11 WhiteBoard 

The design is object oriented and consists of classes such as client, shape, 
frame and socketbase The application is structured into the following layers 
Shape layer, Frame layer and Bytestream layer The Shape layer interprets 
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Figure 2 1 Software system architecture 


the data in terms of the shape class which is further subdivided into straight 
line, rectangle, ellipse and curved line A shape can be thought of as an object 
with the attributes of Type, Identification, Pen size, Colour and Position on 
the screen The protocol interface to the Shape layer is in terms of objects 
with the above attributes 

The shape layer passes on the shape objects to the frame layer which 
packetises and sends the shape over the network through the Bytestream 
layer At the receiver, the frame layer passes pointers to the shapes to the 
shape layer which then displays them calling the appropriate display func 
tion The frame layer primarily consists of the class Client which is derived 
from the class Multicast SocketBase (derived from SocketBase class) and 
provides a handle to the upper layer This handle mentions only the shape 
to be written on to the remote machines The frame construction unit gen 
erates the appropriate frame and calls the handle of the Bytestream layer to 
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Figure 2 2 The interface between the different layers in WhiteBoard 

transmit the packet The frame layer also does session maintenance, queue 
and list management The Bytestream layer communicates directly with 
the network The class SocketBase defined here provides the handle to the 
upper layer to start the session The class Multicast SocketBase is derived 
from the class SocketBase and pro\ ides the multicast support The support 
for reading and writing is asynchronous The packets are multicast to the 
group whenever an active member puts up a shape m his/her window All 
the members pick up the shape by listening to the port which identifies that 
paticular multicast group 

2 12 Slide display Component 

The modular structure of the WhiteBoard developed by Gupta and Mukhopad 
hyay [1] makes it easy to incorporate new features or enhance existing features 
in the WhiteBoard since only a couple of modules needed to be restructured 
with no changes to other modules Thus, SlideTalk is essentially the addition 
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of the slide and voice components to WhiteBoard 

In SlideTalk, the display window of the whiteboard is used to display the 
slides Ghostview for Windows an interpreter for PostScript page descrip- 
tion language, is used to place the slide into display window of the white- 
board The lecture slide to be displayed by the speaker to the multicast 
group is first opened in the GhostView application which is run in the back- 
ground The content of the slide opened in GhostView is then trnasferred to 
the Clipboard of the Windows in bitmap format Windows Clipboard allo- 
cates a separate memory block for Clipboard data Thus any changes made 
to the Clipboard data do not affect the original file containing the lecture 
slide Also, the GhostView application can be freed for reuse Now, by using 
the simple functions of the Clipboard, the same slide data is transferred to 
the SlideTalk application as a bitmap object with its necessary colour mfor 
mation, size of the slide etc Simultaneously, the Clipboard is emptied to free 
the memory block used by the Clipboard and to free the Clipboard which 
may be required for use by some other application 

At the speaker’s machine, the slide file is actually opened m the GhostView 
application and the name of this slide file should be obtained by the local the 
SlideTalk application for communicating it to the other members of the mul 
ticast group For this transfer of the file name from the GhostView applica 
tion to the SlideTalk , global memory is used To achieve this exchange of file 
names, between the GhostView and SlideTalk applications using global mem 
ory, GhostView is first allocated a portion of the global memory into which 
it writes the filename Then, by using PostmessageO or Sendmessage 0 
function the pointer to that memory block is communicated to SlideTalk 
Thus, the filename of the slide file in the form of a character string is now 
available to the SlideTalk application The filename of the slide to be dis 
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played is multicast The ShdeTalk application at the other group members 
receives the slide file name message and follows the same procedure as that 
at the speaker to display the PostScript file m the Remote Tutor Window 

2 13 Voice component 

In his implementation of the voice component for ShdeTalk, Kohli used a 
double buffering mechanism for packetisation of voice and continuous playout 
For digitisation of voice, two buffers are supplied to the WAVE device, and 
a timer of 100msec (corresponding to the approximate time to fill a 996 byte 
buffer with voice data sampled at 10000 samples per second) is started At 
timer notification instances the buffers supplied to the WAVE device for 
filling are read out and sent to the multicast group The two buffers are used 
alternately 

During playout two buffers are set aside for receiving the voice data and 
plaj ing it When a voice data is received from the network, the data is copied 
to the free buffer if one is there, and sent to the WAVE device for playback 
The reproduced voice had considerable clipping and was severely dis 
torted The problems with this implementation, and also the features of the 
new design are detailed m Chapter 3 

2 2 Specifications of the Remote Tutor 

As mentioned in section 1 22, Remote Tutor facilitates lecture and seminar 
deliver} over the Internet The Remote Tutor consists of three components 
The Teacher’s Console the Students’ Consoles and the Lecture Manager 
The fullfiedged Teacher s Console will typically be a Pentium PC with Win 
dows95 and multimedia attachments such as a Sound Blaster, video frame 
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Figure 2 3 Conceptual view of Remote Tutor 


grabber encoder and compression hardware and software The fullfledged 
Student’s Console can be a low cost 486 or Pentium PC with Windows95 
Sound Blaster and video decoder software The Lecture Manager controls 
the flow of information from and to the teacher and the students In the 
present implementation, the Lecture Manager resides with the teacher The 
conceptual view of Remote Tutor is show n in Figure 2 2 

2 2 1 Teacher’s Console 

At the teacher’s console, the teacher has the ability to organise, edit and 
record a lecture and start the delivery of the lecture over the network The 
method of logging m and teacher identification is discussed m the section on 
Lecture Manager Upon logging in as an authorised teacher, the teacher can 
organise a lecture in units of slide files The slide files are PostScript files and 
the sequencing of the units is done before the start of the lecture delivery 
The teacher can associate audio files ( wav), text files ( txt) and video files 
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( mpg) with each slide file A typical lecture organisation is shown in the 
Figure 2 2 3 When the teacher starts the lecture delivery, a WhiteBoard is 
presented, on which slides will be displayed The teacher can either playout 
a recorded lecture or deliver the entire lecture online The structure of the 
recorded lecture is discussed in Chapter 4 In case of an online lecture the 
teacher’s voice will be heard at the students console, however the students 
can speak only w ith the teacher’s permission While playing out a recorded 
lecture students cannot intervene and ask questions At the teacher’s con- 
sole controls are provided to switch the audio system on or off, to mute or 
activate the microphone and adjust the volume control 

2 2 2 Student’s Console 

When a student starts the application, his login id and password are regis 
tered and maintained by the Lecture Manager The student then joins the 
lecture group and can participate in the lecture The Lecture Manager in 
vokes an FTP session with the teacher’s machine to download all the slide 
files for the lecture The student then gets a screen identical to the teacher s 
console m “look and feel” but with a few exceptions The Student will have 
no option to view the organisation of the lecture and has to seek prior per- 
mission from the teacher before communicating (annotating, speaking, etc ) 

2 2 3 Lecture Manager 

The Lecture Manager manages the teacher’s and the Students’ registration, 
the lecture file organisation and recording and the file transfers from the 
teacher to the Students before the start of the lecture 

The teacher can record the units at his leisure before the start of the 
lecture The lecture organisation is visible only to the teacher The students 
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Figure 2 4 A Typical Lecture Organisation 


get the required files on authentication by the Lecture Manager via FTP 

2 3 Design Issues for the Remote Tutor 

In the following we briefly discuss some of the issues m the design of the 
Remote Tutor application 

The Communication Model 

The communication model for RemoteTutor follows the IP multicast based 
group deliver* model In IP multicast, a multicast address defines a group 
Data sources simpl) send data to the group address and receivers gather the 
data by listening to the group address Individual members do not need to 
know the number of active senders at any instant or the IP address of the 
other members of the group This model ensures a consistent shared window 
among the group members, and utilises the network bandwidth efficiently 
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UDP has been chosen as the underlying transport protocol 

Concurrent Update 

The application specifications require that the Remote Tutor must provide a 
concurrent update m any part of the window This means that the packets 
must be identified uniquely and queueing must be provided to display at the 
appropriate time In the multicast environment, every packet sent to the 
network is also received back This leads to the shift of control to a different 
message handler The same problem occurs when two members of the group 
attempt to write simultaneously In order to counter this problem, for each 
received message a deuce context is allocated, the window updated and the 
device context deallocated For local graphics a separate device context is 
maintained which helps identify local and remote objects 

Ordering 

The ordered delivery is not very stringent for the annotations and graphic 
data but there is a consistency requirement and a need for local ordering 
The local ordering is done by providing a sequence number to identify each 
object and each host orders the objects for display depending on the order 
of their arrival A cross linked chain of host list and shape list achie\ es the 
order which ensures that all objects corresponding to a particular host are 
m order even if the\ arrived out of order 

Voice data is to be transported and used m real time and ordered delivery 
is required This is achieved by providing a sequence number to the voice 
packet and dropping out of sequence packets at the receiver 
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Jitter 


In an asynchronous network environment, the delay jitter and packet loss are 
inherent problems For real time traffic such as voice, the effect of jitter must 
be overcome to avoid distortions For each audio packet, the total latency will 
have the following components The time spent m the audio device pipeline 
at the source, the time spent m the network interface waiting to access the 
network, the physical transmission time and the time spent queued at the 
receiver before playout The effect of jitter can be reduced by using an initial 
playout delay measured as the difference between the time instants at which 
the first sample was received and that at which it was played out At the 
receiver the use of de jittering buffers takes care of the constant rate playout 
of voice 

Packet Loss 

The graphic, annotation and control data need reliable delivery Recall that 
we use UDP at the transport layer Therefore, reliability should be imple 
mented in the application However, the present version of the application 
does not provide for reliable delivery 

Buffer Management for Voice Data 

In order to provide for minimum delay at the audio encoder, a double buffer 
mg scheme is used One buffer is used for the capture of voice from the 
hardware while simultaneously the second buffer is used for sending the cap 
tured data over the network When the data in the second buffer has been 
sent, the buffer pointers are switched A similar scheme is used at the re 
ceiver 
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2 4 Summary 


A few features that have been specified for RemoteTutor have been imple- 
mented m earlier telesemmanng tools like the whiteboard and SlideTalk 
SlideTalk was built on whiteboard and we develop Remote Tutor on SlideTalk 
Although SlideTalk had a voice delivery capability, it had to be redesigned to 
improve the voice quality Also many new features are specified for Remote 
Tutor We implement some of these features In the next two chapters, we 
discuss the voice component implementation and the Lecture Manager for 
the Remote Tutor 
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Chapter 3 

Design and Implementation of 
Voice Component 


In Remote Tutor , a large fraction of the data that is exchanged in real time 
is voice The implementation of features like lecture recording and playback 
of recorded lecture are greatly influenced by the voice component unplemen 
tation In this chapter the specifications of the voice component are given, 
and the design and implementation details are also discussed 

3 1 Specifications of Voice component 

The voice is encoded in PCM format To achieve telephone qualify voice 
the input voice is sampled at 8000 samples/sec The voice is single channel 
or mono mode, and a sample is encoded into 8 bits These specifications are 
to be supplied to the WAVE device through the structure PCMWAVEFORMAT 
while opening it for recording and playout (See Appendix A for details of 
PCMWAVEFORMAT ) 
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3 2 Design of Voice Component 


The voice component of [3] is redesigned to improve the reproduced sound 
quality For good quality of the reproduced voice, the temporal coherence is to 
be maintained when the voice packets are played out Temporal coherence 
refers to the time relationship between two encoded packets that must be 
preserved at playout time Any variation in this relationship will have an 
annoying effect on the reproduced voice Another important issue while 
designing the voice component is that the recording and playout have to be 
lossless It means that there should be continuity between two successive 
packets of the voice, and there should not be any gaps during plajout 

To achieve lossless recording of voice, a double buffering scheme is em 
ployed Two buffers are used for recording and these two buffers are filled 
by the WAVE device alternately Once a buffer is filled it is returned to the 
application, and the other buffer takes its place The data is copied from 
the filled buffer and is sent to the multicast group after which that buffer is 
immediately sent to the input queue of the WAVE device for refilling This 
way, there will alwajs be one buffer m the queue, before a buffer gets filled 
and is returned to the application Continuity is achieved b\ the double 
buffering scheme 

Continuity is achieved for playout in the same way but here the number of 
buffers to be used was influenced by other factors like playback of a recorded 
lecture, and the amount of initial playout delay to be provided 

Temporal coherence of voice during playout is affected by the variable 
delays that the packets experience from recording at the sender to playout 
at the receiver A major factor that contributes to the variable delay is 
that introduced by the various network protocols that a packet traverses To 
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reduce the effect of varying delay, an initial playout delay is introduced when 
playout begins After receiving the first packet, the playout begins only after 
this playout delay This way, a certain number of buffers are ensured in the 
input queue of the WAV E device at any particular time, depending upon the 
amount of playout delay introduced 


3 3 Implementation 

3 3 1 Configuration of the WAVE device 

The WAVE device is opened for recording by the function, 

wavelndpendphWaveln IDDevice lpwf dwCallback 
dwCallbacklnstance fdwOpen) 

while for playout the device is opened by the function, 

waveQutOpen( lphWaveOut IDDevice lpwf dwCallback 
dwCallbacklnstance fdwOpen) 

where 


LPHWAVEIN lphWaveln 

LPHWAVEOUT lphWaveOut 

UINT IDDevice 
LPWAVEFQRMAT lpwf 
DWORD dwCallback 
DWORD dwCallbacklnstance 
DWORD fdwOpen 


/* variable to receive handle to 
input device */ 

J* variable to receive handle to 
output device */ 

/* identifier of the device */ 

/* address of structure with device format */ 
/* address of callback window handle */ 

/* Instance data */ 

/* open option */ 
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The specifications of the voice component is contained in an instance of 
the structure PCMWAVEFORMAT, whose address is cast as LPWAVEFORMAT, and 
passed to the above functions as their third argument (In the earlier imple- 
mentation of the voice component the address of the WAVEFORMAT member of 
PCMWAVEFORMAT structure, was passed to these functions as their third argu 
ment ) During recording, the WAVE device is configured in such a way that 
it will send a message to the application when a buffer is filled and is to be re- 
turned to the application by supplying the handle to the application window 
as the fourth argument of the function wave InOpen The same procedure is 
used when a buffer has completed play out (In the earlier implementation, 
the application was not receiving or handling these messages from the WAVE 
device ) 

3 3 2 Playout Delay 

Each voice packet will contain 992 bytes and will amount to a playing time 
of 124 msec As mentioned before, an initial playout delay is needed to 
minimise the effect of delay jitter on the reproduced voice We introduce a 
playout dela\ corresponding to 600msec of speech There are ten numbers 
of audio buffers allocated to receive incoming voice packets from the net 
work When the WAVE device is opened for playout it is paused by the 
function waveOutPauseO, and playout is started only after accumulating 
five voice buffers m the input queue of the WAVE device (corresponding to 
600 msec of speech) In the event of the input queue of the WAVE device 
being empty, it is assumed that the transmitter WAVE device has paused 
and is not transmitting voice data In this case the next incoming packet is 
also be delayed (till five packets are accumulated) before playout (In the 
earlier implementation, there was no playout delay ) 
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3 3 3 Event driven implementation 

The earlier implementation was time driven in which a timer is started when 
a buffer is supplied to the WAVE device for recording, the value of the timer 
being the time for filling the buffer At the timer notification instances, the 
buffer, one of the two used in the double buffering method, whose turn it 
was to be transmitted would be sent for transmission On the receiver when 
a voice packet is received, of the two buffers, the one that is empty, if there 
is one, is filled and sent to the WAVE device for playout 

In the event driven approach that we use, we open the WAVE device 
for recording (playout) m a configuration m which the WAVE device would 
notify the window s about filling (emptying) the buffer by sending a window s 
message to the application 

3 4 Flow Diagrams for Recording and Play- 
out 

3 4 1 Recording 

The flow diagram for recording process is shown in Figure 3 4 1 and Fig- 
ure 3 2 

When the menu option voice is selected, the WAVE device is opened to 
recene voice data m 8 bit PCM format Two buffers, each of 992 bytes ca 
pacity, are allocated to the WAVE device These are alternately filled b) the 
device Initially these two buffers are supplied to the WAVE device and the 
device is started using the function wavelnStart () Also, the WAVE device 
is opened in such a way that when a buffer is returned by it, a message would 
be sent to the application window notifying this event The application wm 
dow catches this message and processes it In the message handling function 
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Figure 3 1 Flow diagram for to respond to the voice menu command 



Figure 3 2 Flow diagram for message handling in the recording process 
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of this message, the content of the buffer is copied, and a voice packet is 
made and sent to the multicast group The buffer is again sent to the WAVE 
device queue for refilling These events continue till the user stops the voice 
If the menu command is of the user stopping the voice, then, in this message 
handling function, the WAVE device is reset, the buffers deallocated, and 
the WAVE device is closed 

3 4 2 Playout 

The flow diagram for message handling during the playout process is given 
in Figure 3 3 When the FIRSTOFOBJ packet is received for voice , an object 
voice of the class TSound is instantiated The WAVE device is opened for 
playing out the incoming voice packets continuously The parameters are 
set as in the case of recording The device is opened in such a way that 
on returning a buffer after playing out that buffer, a message is also sent to 
the application window This message is handled by the application We 
have allocated 10 buffers each of 992 bytes for receiving the packets On 
opening the WAVE device, the playout doesn’t start immediately, instead 
the WAVE device is paused by the function waveOutPauseO This enables 
us to introduce an initial playout delay This playout delay is required to 
avoid playout jitter that might result from the varying delays between two 
successive voice packets To introduce this playout delay, once the queue m 
the WAVE device is empty, the WAVE device is paused until 5 packets are 
accumulated for playout On recievrag the sixth packet, the WAVE device 
is restarted by the function wave OutRest art () A counter indicating the 
number of outstanding buffers in the playout queue is incremented every 
time a packet is sent to the WAVE device for playout Also there is a 
pointer to the next empty buffer m the playout queue of the WAVE device 
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Figure 3 3 Flow diagram for message handling during playout (bp is the 
buffer pointer) 


24 







When a voice packet arrives, it is placed m the buffer indicated by this 
pointer and the counter is incremented The message handling function of 
the playout process just decrements the counter that indicates the number 
of buffers m the WAVE device queue Once the counter is zero, the WAVE 
device is paused again and it will be restarted only when this counter reaches 
6 This works fine especially when the application pauses voice during slide 
invocation, drawing graphics etc 

On receiving the ENDOFOBJ packet from the network, the playout process 
is stopped, the buffers are deallocated and the device is closed 

3 5 Summary 

We have discussed the design issues and implementation details of the voice 
component for Remote Tutor The implementation is event driven and delay 
jitter is avoided by providing adequate de jittering buffers The differences 
with the voice component of SlideTalk has been emphasised In the next 
chapter, we discuss the Lecture Manager and the design and implementation 
details of the features we have implemented m this thesis work 
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Chapter 4 

Design and Implementation of 
Lecture Manager 


As seen in Chapter 2, the Lecture Manager manages a lecture session, does 
recording, storage and retrieval of a lecture, and provides administrative 
controls and maintenance functions In this implementation of Remote Tutor , 
the Lecture Manager’s functions are assumed to co-reside with the tutor s 
console Figure 4 shows a conceptual diagram of the Lecture Manager 

4 1 Overview of the Lecture Manager 

4 11 Lecture Management 

Student and Tutor Registration 

A GUI has been implemented for student as well as the tutor, to log in to 
a particular lecture session For a student to log in it is needed to supply 
his/her name and roll number to the application through a dialog box The 
student authentication is done at the tutor’s console and appropriate mes 
sages are sent to the student from the tutor’s console When a student wants 
to register for the first time, he is asked to get the lecture related files from 
the Lecture Manager using ftp The students who are already registered for 
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Figure 4 1 Conceptual view of Lecture Manager 


the lecture will be prompted to proceed with the login process The tutor can 
log in for a lecture session by giving the multicast address for that lecture 
This feature has been implemented by Madhu Bajpai 

Allocation of Multicast Address 

When a tutor logs in for a lecture session the Lecture Manager has to dy- 
namically assign an unused multicast address, from a given set of multicast 
addresses, to that lecture session This multicast address will be sent to the 
students when they log m for that particular lecture session At the end of 
the session, the multicast address is freed and could be allocated again for a 
later session This feature of Lecture Manager is not yet implemented 

Late Join 

A student can join for a lecture session late, by the same procedure as given 
above However, the student only reveives the data from the instant he logs 
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in This feature has been implemented in this thesis 


Offline Browsing of a Lecture 

By retrieving a recorded lecture from the Lecture Manager, a student can 
browse through it at leisure In this implementation, lectures w ill be replayed 
at the same pace at which they were delivered The only browsing controls 
availabe to the student while browsing a stored lecture will be to go to the 
next slide to go to the previous slide and pause and resume the playback 

4 12 Recording, Storage and Retrieval of a Lecture 

Lecture Recording by Tutor 

A tutor can record a lecture offline The lecture will be recorded in a lec file 
which contains the voice and control commands for invoking and sequencing 
through various slides and graphic objects 

Organisation of Files for a Lecture 

As mentioned in Chapter 2 the various files that constitute a lecture are 
organised m a specified format The tutor has to organise a lecture prior to 
the start of the session The Lecture Manager provides the necessary user 
interface for this function This feature has been implemented in this thesis 
The details are explained in section 4 2 1 

Lecture File Manager 

When a tutor organises a lecture, the relevant lecture related files are brought 
together into a new directory created for the lecture by the Lecture Manager 
To attend this lecture, contents of this directory are to be copied by the 
students during their registration 
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Viewing the Lecture Organisation and Notes 

The lecture organisation file could be viewed on a tutor s console in a sepa 
rate window This implementation allows the tutor to simultaneously view 
corresponding notes files There is also a feature that allows the tutor to 
view and scroll thiough the lecture notes from text file 

4 13 Administrative Controls and Maintenance 

The administrative functions will include those required by the academic 
sections of colleges and comprise of activities like course announcements and 
maintenance, lecture scheduling, course evaluation and grading assignment 
download and submission etc , These functions are not implemented m this 
version 


4 2 Design and Implementation of Lecture Or- 
ganisation 

4 2 1 Structure of the Lecture Organisation File 

The lecture oi gamsation file is an ASCII text file with lec extention The 
names of files that constitute a lecture are entered m this file when a tutor 
organises his lecture The structure of this file is as shown belov, 


SI No Unit 

No 

1 1 

2 1 

3 2 


Unit Name No of 
Pages 

try ps 12 

x mpg 

pdp ps 5 


Next Prev 

y n 

n y 
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Figure 4 2 Opening dialog box for lecture organisation 

Here each PostScript file is considered to to be a unit of lecture and there 
can be othei files like mpg, avi that are associated with a particular unit 
This file reflects the association of files to different units The fields Next 
and Prev are used to indicate if that unit is the last or the first unit of a 
lecture This file is used to scroll backward and forward among the different 
slide files while delivering the lecture This file is also used m sending the 
lecture related files to the participants of the lecture during registration 

4 2 2 GUI for Lecture Organisation 

To prepare the lecture organisation, a tutor has to log m as a Tutor by 
running the Remote Tutor application In the File menu there is Prepare 
Lecture option On selecting this option a Dialog box appears as shown m 
the Figure 4 2 

The tutoi has to provide the name of the course and the directory m 
which his lecture files reside On selecting the Proceed option, another Dialog 
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Leclure Organisation 



Figure 4 3 Dialog box for entering file names 


box appears as shown in the Figure 4 3 

All the lectuie files are to be entered through this dialog box by clicking 
the Next button until the last file, for which Over option is to be clicked 
The files are to be enteied as shown m the example file organisation above 
All the files enteied by the tutor are copied from the tutor’s director} 
(as given through the first dialog box) to the newly created directory which 
caines the same name as the course name given through the first Dialog box 
Also a lec ASCII text file w ill be created and all the file entries are written 
into it This file is exclusive to the tutor s console and will not be sent to 
the students It will be m the Remote Tutor directory The students will be 
asked to ftp, the contents of this newly created directory as lecture files, prior 
to the start of the lecture session At the student’s console, the application 
will create a directory by name ’’Course name” as selected by the student 
The lecture files downloaded from the Lecture Manager will be put m that 
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directoiy 

As mentioned before, another use of having the lecture organisation file 
(coursename lec) is to facilitate forward and backward scrolling among the 
different slide files A doubly linked list is prepared, with all the slide file 
names and then respective ‘ number of pages ’ information, in the information 
content of each node in the list Scrolling forward and backward among slide 
files is then achieved by traversing the list in the respective directions 

4 3 Design and Implementation of Recording 
and Playback of Lecture 

4 3 1 Design Issues 

Memory Access Time 

The key pai ameters to be considered m the design of recording and plaj back 
of real time data generated during a lecture aie 

• The disk read/ write time consisting of the seek time and the actual 
block transfer time from/to the disk 

• The time foi processing a data for recording or playback 

• The time between successive data generation instants during lecture 
recoidmg For playback the corresponding parameter is the time to 
fetch a unit of real time data before the previous has been completely 
played out 

None of these parameters are constant It is important to keep the sum of 
the disk read/wnte time and the data processing time considerably lower 
than the time between two successive data generation instants and this will 
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be oui objective m designing lecture recording feature Since voice is the 
major source of real tune data, we will assume that the time between two 
successive data genrations instants is roughly 124 msec, corresponding to the 
voice packet size Our objective is achieved by buffering the data generated 
during recording, and writing a batch of twenty packets (voice or control) 
to the disk in every write operation Similarly a batch of twenty packets is 
read from fiom the disk during playback 

Temporal Coherence of Voice 

The main issue while dealing w ith \oice is that its temporal coherence should 
be maintained dunng playback Maintaining temporal coherence by reading 
one packet at a time and playing it would have been impossible and meffi 
cient Reading and writing twenty packets of data at a time eliminates this 
problem 

Capture and Maintenance of Correspondence of Voice to Other 
Real Time Data 

In a lecture, most of the time, the voice will be m reference to an action like 
invoking a slide 01 di aw mg a figure on the w lnteboard During recording of 
the lecture, this coirespondence of voice to a particular type of data has to be 
captured Also, during playback of a recoided lecture this correspondence 
has to be maintained For example, if the tutor invokes a slide and talks about 
the content of that slide during playback of that lecture, the slide should be 
on the whiteboard before the explanation of that slide begins In the Remote 
Tutor , only one type of object will be generated at any time instant During 
recording, the real time data that is generated (voice and control signals) are 
recorded in the ordci of their generation, and m playback the same order is 
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maintained Thus the correspondence of voice to slide graphic objects etcare 
captured and maintained during recording and playback We mention here 
that voice is paused every time a control signal of any kind is generated This 
means that during playback of a recorded lecture, synchronisation across data 
streams is maintained upto a resoultion of 600 msec 

4 3 2 Implementation 

We have defined a class Reed which contains all the data and functions needed 
during recording and playback We have also defined a structure RecPly, as 
a member of this class that contains the buffers to be filled with the data In 
the structure RecPly there are 20 buffers to collect data or events, and there 
aie some conti ol flags foi identification of the data The entile structure will 
be recorded or placed back at a time (See Appendix B for details of this 
class and structure ) 

On selection of Record/ Playback option m the File menu, two objects of 
the Reed class are instantiated Two objects are needed to maintain contmu 
lty during playback and recording During recording buffers of the RecPly 
are filled sequentially with the data that is gernerated, m one of the two ob 
jects that are instantiated Once all the buffers are filled in one object, that 
object’s RecdStrt function is called which records those 20 buffers contain 
mg data When it is being recorded, the second object would be collecting 
data This double object scheme enables lossless recording 

During plaj back of a recorded lecture temproal coherence for the com 
posite lecture data stream is maintained by synchronising at the follow mg 
instants the WAVE device completing the palyout of a buffer or the expiry 
of a 115 msec timer This timer is used to ensure that at least one data 
packet is processed every 115 msec (Likewise, during recording, a timer is 
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Figure 4 4 Flow diagxam foi recording process 

used to ensuio that at least one data packet is recorded every 115 msec If 
theie is ncitliei voice nor control data during this period an empty packet is 
lecorded ) llo msec is chosen becuase this approximately corresponds to the 
time between successive voice packets of 124 msec The MSWmdows timer 
is not very accurate and achieving an exact 124 msec time out is impossible 
If the timei takes more than 124 msec, we have observed that the WAVE 
device input ciueue gets emptied out causing a 600 msec break m the voice 
during playback Therefoie we use a 115 msec timer When a buffer is played 
out by the wave device another data packet is read immediately This is be 
cause, when a continuous stream of voice data is recorded, during playback, 
the pla}back process will be controlled bj the WAVE device, rather than the 
above mentined timer However the timer is important, because during slide 
invocation in recording and playback, otherwise the synchronisation could be 
disturbed since voice is paused 
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Figure 4 5 Flow diagram for playback process 


It has been mentioned earlier that reil time data is read m batches of 20 
buffers To ensure that the playout buffers do not underflow the next batch 
is read when the 12 from the previous batch have been played out 

During online delivery of lecture when anj real time data is generated 
and it is to be transmitted to the multicast gioup, a packet is generated 
with this dal a and some additional control signals as the payload of the 
packet Dining iccoiding, a smnlai packet is generated with the data, but 
the picket is cont lined m the VOICEBUF member of the structure RecPly 
During playback, the VOICEBUF incmbei undeigoes the same processes, as a 
packet received liom the network would, and the respective events also take 
place The difference is that these events aie transmitted to the multicast 
group 
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4 4 Summary 


An overview of Lecture Manager is given m this chapter The GUI for lec 
ture organisation by tutor has also been discussed The features, issues and 
implementation details of lectuie recording and playback also have been dis 
cussed in detail The next chapter concludes this thesis and discusses scope 
for future woik 



Chapter 5 

Testing and Future Work 


5 1 Testing 

The current u lsion oi Ht mail Iuloi Ins hi t n t< ste d ( \l< nsiu h mil is i\ ul 
xblc iiom bet i testing horn the I< lem dies l dun lion Deptt ollleelutil 
Engine ermg, II J h input Verne is oi tdt plume epiaht\ nulls lsevpeeted 
Recording md pi n bae k oi le ( I m < s Ium dso he ( n le steel and idimonstn 
tion recorded Ice Ime u e omp uue s the ehstrilmlum 1 In Ihmott Jutin has 
also boon denionsti Reel during Icthkn(i‘)8 il Ill,hinpui tlunri). leluu.m 
1998 and no bugs we k obsened 1 his thesis will dso be tie knelt el usitif 
Rimoit Pulor md will use a m mde d le e line uni a live delnm component 

5 2 Future work 

/femote l\it oi with its pie sent le iluies is an eve lie nl tool loi tele sent 
mamg The present h unewoik eoulel be used to mempmtte <i real tune 
video conferene mg ieatuie using simihu lethuiepus A silence tie lee turn m 
speech compression algorithm eoulel be me en pen ited to enable bet mode ol 
communication during audio conic mice Some form of cue upturn also timid 
be incorporated Other fe itures that could make Jh mote tutor versatile 



are, display of MSWord and PowerPoint slides, and multiple session man 
agement in the Lecture Manager Also by using the Multithreading feature 
of Wmdows95 some restrictions on multiple object selection in the present 
application could be removed 



Appendix A 


Multimedia Waveformats 

A 1 WAVEFORMAT 

The WAVEFORMAT is given below 


typedef struct wavef ormat_tag-C 
WORD wFormatTag 
WORD nChannels 
DWORD nSamplesPerSec 

DWORD nAvgBytesPerSec 

WORD nBlockAlign 

}WAVEFORMAT 


The WAVEFORMAT structure describes the format of waveform data 
Only format information common to all waveform data formats is included m 
this structure For formats that require additional information, this structure 
is included as a member of another structure, along with the additional 
information 
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MEMBER 


DESCRIPTION 


wFormatTag 


nChannels 

nSamplesPerSec 

nAvgBytesPerSec 

nBlockAlign 


Specifies the format type The currently defined 
form format type is WAVEFORMATPCM which 
specifies that the waveform data is pulse code 
modulated (PCM) 

Specifies the number of channels m the waveform 
data Monaural data uses two channels 
Specifies the sample rate m samples per second 
Specifies the required average data transfer 
rate m bytes per second 

Specifies the block alignment m bytes The 
block alignment is the minimum atomic unit of 
data 


A 2 PCMWAVEFORMAT 

typedef struct pcmwaveformat_tag{ 

WAVEFORMAT wf 
WORD wBitsPerSample 

> 

The PCMWAVEFORMAT structure describes the data format for pulse 
code modulated PCM waveform data 
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MEMBER 

wf 

nBitsPerSample 


DESCRIPTION 


Specifies a WAVEFORMAT structure containing 
general information about the format of the 
waveform data 

Specifies the number of bits per sample 
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Appendix B 
Reed Class 


Class Reed, for recording and playing back events 

class Recdply{ 
private 

mt non 

Public 

FILE *RCD *PLF 

int numst /* points to the RObj member */ 
RecPly RObj [20] 

TRecdO ■[ > 

TRecd(mt) 

~TRecd() 
void InitStrtO 
void RecdStrt(FILE*) 
void PlayStrt(FILE+) 

} 

struct RecPly{ 
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mt type 

int buflength /* length of the buffer */ 

BYTE VOICEBUF [1024] /* buffer to hold data */ 


> 
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